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(54) Digital code interpreter 

(57) An apparatus for processing digital audio-vis- 
ual data, in particular a decoder for a digital television 
system, comprising one or more hardware devices for 
transmission and reception of data external of the appa- 
ratus, the apparatus further comprising a data process- 
ing system including a first virtual machine adapted to, 
inter alia, receive code written in an interpretative lan- 
guage downloaded via one or more of the hardware 


devices, said virtual machine being adapted to distin- 
guish between code written in at least two interpretative 
languages in dependence on the structure of the 
received code and to pass such code to a correspond- 
ing interpreter 4278, 4279 means for interpretation and 
execution with reference to a common or specific func- 
tion library 4520, 4530. 
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Description 

[0001] The present invention relates to an apparatus 
for processing digital audio-visual data, in particular a 
decoder for a digital television system including an inter- 
preter. 

[0002] A software based system for controlling a 
decoder in a digital television system that uses a virtual 
machine and run time engine for processing digital tele- 
vision data and downloaded applications is described in 
the PCT application PCT/EP97/02116. Ttiis system 
possesses a number of advantages in comparison with 
previously known systems for receiver/decoders, nota- 
bly in regard to the independence of the application lay- 
ers of the system to the hardware elements of the 
manufactured decoder through the use of a virtual 
machine structure. 

[0003] Although the use of the virtual machine and 
run-time engine permits the system described in this 
application to be largely independent of the hardware 
level of the system, the openness of the system is nev- 
ertheless limited by the code used to write the applica- 
tions which sit on top of the virtual machine level in the 
system. As described in the application, code is written 
in an interpretative language, which is downloaded into 
the receiver from a broadcast centre and interpreted by 
an interpreter in the virtual machine. 
[0004] Although the code can be chosen to be a com- 
mercially known and standardised language, problems 
can arise, for example where the receiver has to proc- 
ess applications written in two or more different codes. 
This problem can arise, for example, where the decoder 
is introduced in a broadcast system in which the existing 
decoders in the field are adapted to receive applications 
written in code different from that used in the present 
decoder. In such a case, the operator may be obliged to 
download a given application twice; once as written in 
the original language for the existing decoders and once 
as written in the new code for the new decoders. As will 
be clear, such an operation is relatively inefficient in 
terms of the use of bandwidth. 
[0005] It is an object of the present invention to over- 
come the problems of the prior art system. 
[0006] According to the present invention, there is pro- 
vided an apparatus for processing digital audio-visual 
data comprising one or more hardware devices for 
transmission and reception of data external of the appa- 
ratus, the apparatus further comprising a data process- 
ing system including a first virtual machine adapted to, 
inter alia receive code written in an interpretative lan- 
guage downloaded via one or more of the hardware 
devices, said virtual machine being adapted to distin- 
guish between code written in at least two interpretative 
languages in dependence on the structure of the 
received code and to pass such code to a correspond- 
ing interpreter means for interpretation and execution. 
[0007] By providing a virtual machine adapted to dis- 
tinguish between received code together with a plurality 
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of interpreter means for interpreting such code, the 
present invention avoids the problems associated with 
the prior art systems and enables the machine to proc- 
ess instructions arriving in different interpretative lan- 
5 guages. A fully open system, both in relation to the 
upper application and lower hardware interfaces may 
thus be provided. 

[0008] In one embodiment, the virtual machine distin- 
guishes between interpretative code in at least two 

10 interpretative languages based on the characteristics of 
a header message associated with a module of code in 
one of the languages. In particular, the virtual machine 
may distinguish between interpretative code based on 
the presence or absence of a header message associ- 

75 ated with a module of code in one of the languages. 
Other embodiments can be imagined, where the 
machine distinguishes between code on the basis of a 
"flag" or other code element in or at the end of a stream 
of transmitted code or on the file name of a module of 

20 code. 

[0009] The present invention is particularly applicable 
to the situation in which one or more of the interpretative 
languages corresponds to an object oriented language. 
In such an example, the machine may examine for the 
25 presence of a header message associated with a class 
file in that language. 

[0010] In order to implement the code, each inter- 
preter means may execute code with reference to one 
or more function libraries. Preferably, a common func- 

30 tion library is shared by a plurality of the interpreter 
means, in order to reduce the amount of memory 
needed for the function libraries. 
[0011] Notwithstanding the presence of a common 
function library, one or more of the interpreter means 

35 may execute code with reference to a function library 
exclusive to that interpreter. This may be desirable, for 
example, where certain specialised functions are more 
easily executed by reference to a dedicated function 
library. As will be understood, the size of the system 

40 may be reduced by using function libraries common to 
both virtual machines, wherever possible and/or con- 
venient. 

[0012] Whilst the present invention is particularly 
applicable to a decoder for receiving and processing 

45 digital television systems, it will be understood that the 
principles of the data processing system set out in this 
application may also be applied to other devices for 
handling digital audio-visual data, such as digital video 
recorders and the like. 

so [001 3] In the context of a decoder for a digital televi- 
sion broadcast, the hardware devices of the decoder 
can include an MPEG demultiplexer together with a 
tuner, a serial interface, a parallel interface, a modem 
and one or more smart card readers. 

55 [0014] In the present application, the term "decoder" 
is used to apply to an integrated receiver/decoder for 
receiving and decrypting an encoded broadcast, the 
receiver and decoder elements of such a system as 
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considered separately, as well as to a digital television 
receiver for receiving non-encrypted broadcasts. 
[001 5] There will now be described, by way of exam- 
ple only, an embodiment of the present invention, with 
reference to the attached figures, in which: 

Figure 1 shows an overall view of a digital television 
system; 

Figure 2 shows the elements of an interactive sys- 
tem within the digital television system of Figure 1 ; 

Figure 3 shows the architecture of the software 
based system implemented within the 
receiver/decoder of the present invention; 

Figure 4 shows the architecture of the virtual 
machine within the system of Figure 3, including in 
particular an event manager package, an interpre- 
tation package and a memory package; 

Figure 5 shows the structure of the interpreter used 
in the virtual machine; 

Figure 6 shows the thread handling within the vir- 
tual machine; 

Figure 7 shows the operation of the event manager 
and scheduler of the virtual machine; 

Figure 8 shows the management of the memory 
pool by the virtual machine. 

DIGITAL TELEVI SION NETWORK 

[001 6] An overview of a digital television system 1 000 
according to the present invention is shown in Figure 1 . 
The invention includes a mostly conventional digital tel- 
evision system 2000 that uses the known MPEG-2 com- 
pression system to transmit compressed digital signals. 
In more detail, MPEG-2 compressor 2002 in a broad- 
cast centre receives a digital signal stream (typically a 
stream of video signals). The compressor 2002 is con- 
nected to a multiplexer and scrambler 2004 by linkage 
2006. 

[001 7] The multiplexer 2004 receives a plurality of fur- 
ther input signals, assembles one or more transport 
streams and transmits compressed digital signals to a 
transmitter 2008 of the broadcast centre via linkage 
2010, which can of course take a wide variety of forms 
including telecommunications links. The transmitter 
2008 transmits electromagnetic signals via uplink 2012 
towards a satellite transponder 2014, where they are 
electronically processed and broadcast via notional 
downlink 2016 to earth receiver 2018, conventionally in 
the form of a dish owned or rented by the end user. The 
signals received by receiver 2018 are transmitted to an 
integrated receiver/decoder 2020 owned or rented by 



the end user and connected to the end users television 
set 2022. The receiver/decoder 2020 decodes the com- 
pressed MPEG-2 signal into a television signal for the 
television set 2022. 
s [001 8] A conditional access system 3000 is connected 
to the multiplexer 2004 and the receiver/decoder 2020, 
and is located partly in the broadcast centre and partly 
in the decoder. It enables the end user to access digital 
television broadcasts from one or more broadcast sup- 
ra pliers. A smart card, capable of deciphering messages 
relating to commercial offers (that is, one or several tel- 
evision programmes sold by the broadcast supplier), 
can be inserted into the receiver/decoder 2020. Using 
the decoder 2020 and smart card, the end user may pur- 
rs chase commercial offers in either a subscription mode 
or a pay-per-view mode. 

INTERACTIVE SYSTEM WITHIN THE DIGITAL TELE- 
VI S I ON NETWORK 

20 

[0019] An interactive system 4000, also connected to 
the multiplexer 2004 and the receiver/decoder 2020 and 
again located partly in the broadcast centre and partly 
in the decoder, enables the end user to interact with var- 
25 ious applications via a modemmed back channel 4002. 
[0020] Figure 2 shows elements of the general archi- 
tecture of the interactive television system 4000 com- 
prising in overview four main elements: 

30 1 . An authoring tool 4004 at the broadcast centre or 
elsewhere for enabling a broadcast supplier to cre- 
ate, develop, debug and test applications. 

2. An application and data server 4006, at the 
35 broadcast centre, connected to the authoring tool 

4004 for enabling a broadcast supplier to prepare, 
authenticate and format applications and data for 
delivery to the multiplexer and scrambler 2004 for 
insertion into the MPEG-2 transport stream (typi- 
40 cally the private section thereof) to be broadcast to 
the end user 

3. A data processing system 4008 at the 
receiver/decoder for receiving and processing 

45 downloaded applications and data and for manag- 
ing communication with the other elements of the 
interactive system and the hardware elements of 
the receiver/decoder, the system 4008 including a 
virtual machine with a run time engine (RTE) imple- 

so merited as executable code installed in the 
receiver/decoder. 

4. A modemmed back channel 4002 between the 
receiver/decoder 2020 and the application and data 

55 server 4006 to communicate signals instructing the 
server 4006 to insert data and applications into the 
MPEG-2 transport stream at the request of the end 
user. Information may also be passed in the other 
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direction. 

[0021 ] The receiver/decoder 2020 includes a number 
of devices for communicating with exterior devices 
within the interactive system, such as an tuner for tuning 
the receiver, an MPEG demultiplexer for demultiplexing 
the MPEG signal, a serial interface, a parallel interface, 
a modem and one or two card readers adapted to read, 
for example, credit cards or subscription smart cards 
issued with the system. The characteristics of such 
devices are well known in the field of digital television 
systems and will not be described here in any more 
detail. 

[0022] Similarly, the sorts of interactive applications 
that may be provided (home banking, teleshopping, 
downloading of computer software) will be apparent to 
those in the field and will not be described in more 
detail. While the decoder system architecture described 
below is particularly apt for interactive applications it will 
also be appreciated that the architecture described can 
be used in simpler non-interactive digital TV systems, 
such as a conventional pay TV system. 

DECODER SYSTEM ARCHITECTURE 

[0023] Turning now to the architecture of the system 
within the receiver/decoder shown in Figure 3, it will be 
seen that a layered architecture is used. The first layer 
4100 represents the operating system of the hardware 
of the receiver/decoder. This is a real-time operating 
system chosen by the manufacturer to control the hard- 
ware elements of the receiver/decoder. The real-time 
operating system has a relatively fast response time in 
order to be able to correctly synchronise hardware oper- 
ations. Event messages are passed between this layer 
and the middleware layer 4200 immediately above. 
[0024] The data processing system 4008 sits on top of 
the hardware operating system and comprises a mid- 
dleware layer and an application (or more correctly an 
application interface) layer. 

[0025] The middleware layer is written in a language 
such as C ANSI and comprises the elements of a virtual 
machine 4250 and a number of interfaces 4260 includ- 
ing a graphical interface 4261 , a FLASH/PROM mem- 
ory interface 4262, a protocol interface 4263 and a 
device interface 4264. 

[0026] As with the system set out in patent application 
PCT/EP97/02116 described in more detail in the intro- 
duction, the present invention uses a virtual machine in 
order to provide independence between upper level 
applications and the lower level operating system imple- 
mented by the manufacturer. 

[0027] The interfaces 4260 provide the link between 
operations of the virtual machine and the lower level 
operating system 4100 and also include a number of 
intermediate level application modules more easily exe- 
cuted at this level. 

[0028] The application interface ( AP I) layer 4300 com- 



prises a number of high level packages 4310-4314, writ- 
ten in an object-oriented interpretative language, such 
as Java. These packages provide an interface between 
the applications created by the service provider (inter- 

5 active program guide, teleshopping, internet browser 
etc) and the virtual machine of the system. Examples of 
such applications are given below. 
[0029] The lower level OS is normally embedded in 
the hardware components of the decoder, although in 

w some realisations, the lower level OS can be down- 
loaded. The middleware and application interface layer 
packages can be downloaded into the RAM or FLASH 
memory of the decoder from a broadcast transmission. 
Alternatively, some or all of the middleware or applica- 

15 tion interface layer elements can be stored in the ROM 
or (if present) FLASH memory of the decoder. As will be 
understood, the physical organisation of the memory 
elements of the decoder is distinct from the logical 
organisation of the memory. 

20 

APPLICATION INTERFACE LAYER 

[0030] Referring to the application interface layer 4300 
shown in Figure 3, and as described above, the pack- 
25 ages in this layer are written in an object oriented lan- 
guage such as Java. Each package defines a set of 
class libraries called on during operation of the system. 
In the present system the following packages are 
installed. 

30 [0031] Lang/Util Package 4310. These packages 
define the classes necessary for the manipulation of 
objects by the virtual machine. These class libraries 
normally form part of a standard library associated with 
the object oriented language chosen. 

35 [0032] MHEG-5 Package 431 1 . This package defines 
the classes associated with the manipulation of graphi- 
cal objects on the television display. Such objects are 
distinct from audio-visual data and can make up, for 
example, channel identifiers or text laid over displayed 

40 images. The definition of classes within this package 
should respect the MHEG-5 norms defined by the 
standards ETS 300777-3 and ISO/ISE 13522-5 (and 
the standard ISO/ISE 13522-6 in the case of a Java 
implemented system). 

45 [0033] Toolbox Package 4312. This package contains 
the classes used for downloading and decompression 
of information as well as the classes associated with the 
management of the file system and memory within the 
receiver/decoder and the classes associated with the 

so connection to the internet etc. 

[0034] Device Package 4313. This package defines 
the classes necessary for management of peripherals 
attached to the receiver/decoder, as discussed above 
and including the modem, the smart card readers, the 

55 MPEG flow tuner etc 

[0035] Service Package 4314. This package defines 
the classes necessary for the implementation of devel- 
oping higher level interactive applications, such as man- 
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agement of credit card data etc. 
[0036] DSMCC-UU Package 4315. This package 
implements the protocols necessary for communication 
between a client and a server for data file search and 
reading. Implementation of this package should respect s 
the norm ISO/IEC 13818-6 and directives defined in 
DAVICpart 9. 

[0037] A further layer of interactive applications, writ- 
ten by the service provider and downloaded during 
broadcast as in conventional systems, will be laid over 
the interface packages defined above. Depending on 
the applications to be introduced, some of the above 
packages may be omitted. For example, if the service 
provider does not intend to provide a common way for 
data reading, the DSMCC-UU package may be left out 
of the final system. 

[0038] The packages 4300 provide class libraries for 
an object-oriented programming environment. Their 
class behaviour will depend on the language chosen. In 
the case of a Java application, for example, a single 
inheritance class structure will be adhered to. 

INTERFACE LAYER 

[0039] As shown, the interface layer is composed of 
four modules, a graphics module 4261, a memory file 
management module 4261, a protocol module 4263 
and a device manager 4264. Whilst the modules at this 
level are described as interface modules their function is 
to provide a "glue" layer for the implementation of the 
application interface packages and for the operation of 
the virtual machine generally. 
[0040] The graphics module 4261, for example, pro- 
vides the creation and management of graphical 
objects. It asks the low level OS to display basic graphic 
shapes such as single pixels, lines, rectangles etc. The 
implementation of this module depends on the graphics 
capability of the low level manufacturer's OS. In some 
ways complementary to the MHEG-5 package 4311, 
these functions may be more efficiently executed at this 
code level than in the high level code chosen for the 
application layer above. 

[0041] In a similar manner, the memory file manage- 
ment module 4262 includes low level read/write file 
commands associated with the memory components of 
the system. Typically, the hardware operating system 
only includes commands necessary to read/write a sec- 
tor or page within a memory component. As with the 
graphics module 4261, this module enables a set of 
simpler lower level applications to be efficiently intro- 
duced in the system. 

[0042] The protocol management module 4263 
defines a library of communication protocols that may 
be called upon in communications via, for example, the 
TCP/IP layer of the decoder. 

[0043] The device manager 4264 is slightly different 
from the other modules in this layer in that it provides 
the link or interface between the hardware operating 



system and the layers above, including the other mod- 
ules in the interface layer and the virtual machine. Com- 
mands or event messages that are received/sent to the 
hardware OS from the virtual machine, for example, are 
necessarily passed by the device manager for conver- 
sion according to the interface specifications between 
the two levels. 

VIRTUAL MACHINE DESCRIPTION 

[0044] Referring now to Figure 4, the structure of the 
virtual machine 4250 used in the system of the present 
invention will be described. The virtual machine used in 
the present invention is a pre-emptive multithread type 
machine. The general characteristics of such a machine 
are known in other contexts outside of the audio-visual 
and digital television fields and the following description 
will focus on those areas that are the most specific to 
the present application. 

[0045] The virtual machine is composed of a number 
of elements, which interact broadly as shown in Figure 
4. 

[0046] The scheduler 4270 composed of a thread 
manager service 4271 and a monitor manager service 
4272 forms the heart of the multithread machine. The 
scheduler 4270 orders the execution of threads created 
by applications externally of the virtual machine and 
those created by the virtual machine itself (e.g. a gar- 
bage collection thread as discussed below). 
[0047] The event manager 4273 handles an event 
routing table and the lists of events subscribed to by the 
threads and centralises the dispatch of event treat- 
ments. 

[0048] The memory manager 4274 handles the allo- 
cation and dislocation of the memory zones within the 
system memory and also handles the removal from the 
memory of non-referenced objects (garbage collection). 
[0049] The class manager 4275 charges the classes 
of the application code downloaded in a broadcast sig- 
nal, interacting with the security manager 4280 to check 
the integrity of downloaded code and with the file man- 
ager 4276, which implements the applications. 
[0050] The file manager 4276 carries out the imple- 
mentation of the system files and the handles the mech- 
anism of downloading of interactive applications and 
data. 

[0051] The security manager 4280 handles the level 
of access permitted to downloaded applications, some 
applications having the ability to carry out more opera- 
tions than others in relation to the file system. 
[0052] The interpreter 4277 comprising a bytecode 
interpretation service 4278 and a "m-code" interpreta- 
tion service 4279 handles the interpretation of applica- 
tions written in these two codes, bytecode being 
associated with Java applications and m-code being the 
name given to a proprietary code developed by the 
applicants. As will be discussed, further interpretation 
services can be added if desired. 
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[0053] The operation and implementation of the class 
manager, file manager and security manager may be 
conventional. The description will now focus on the 
operation of the interpreter, the scheduler and event 
manager and the memory manager. 

INTERPRETER 

[0054] Referring now to Figure 5, the operation of the 
interpreter 4277 used in the embodiment of the present 
invention will now be described. As discussed in the 
introduction, the disadvantage of conventional operat- 
ing systems used in decaders proposed to date has 
been their reliance on a single type of code for the high 
level applications. Although the code chosen may be a 
commercially available and widely known application 
code, problems can nevertheless arise in the case 
where it is necessary to maintain a field of a number of 
decoders using different applications written in a 
number of codes. The interpreter of the present system 
permits the interpretation of a number of types of code. 
[0055] As shown, files arriving in the system, whether 
bytecode classes or m-code modules are evaluated by 
the module class manager 4500 according to the struc- 
ture of the file, such that the application code delivered 
to the interpreter 451 0 has an indication of format. In the 
case of a bytecode application, for example, the down- 
loaded class file will have a characteristic identification 
header of 4 octets followed by a version number, also of 
4 octets. The interpreter may distinguish between the 
codes on the basis of the presence or absence of this 
bytecode header. 

[0056] In other embodiments, other characteristics of 
the code types may be used to distinguish between any 
number of application languages, such as the file name, 
for example. 

[0057] Depending on the result of the format indicator, 
bytecode instructions are sent to the bytecode inter- 
preter 4278, where they are executed with reference to 
a function library 4520 associated with the byte code 
instructions, as is conventionally the case with interpre- 
tative code instructions. The function library of native 
code instructions is defined within the virtual machine. 
[0058] In the case of m-code instructions, these are 
passed to a made interpreter 4278. The majority of the 
m-code instructions may be implemented and executed 
with reference to the function library 4520 associated 
with byte-code instructions, and the interpreter 4278 
calls on the library 4520 to execute such m-code func- 
tions wherever possible. 

[0059] In some circumstances, however, some m- 
code instructions may need specific execution functions 
not easily executable with reference to a common func- 
tion library. In such cases, it may be envisaged that the 
instructions be implemented with reference to a sepa- 
rate function library 4530. 



SCHEDULER AND EVENT MANAGER 

[0060] The operation of the scheduler 4270 and event 
manager 4273 will now be discussed, with reference to 

5 Figure 6 which shows the life of a thread within the sys- 
tem and Figure 7 which shows the notification of an 
event to a thread by the system in response to an event 
signalled by the lower level run-time operating system. 
[0061] The description will concentrate on the nan- 

w dling of the creation of a thread which represents an 
execution context in particular resulting from a signalled 
event. It will be understood that a thread may be created 
with the initiation of a command generated by a higher 
level application to be sent to the hardware OS and by 

is the return of this command. A thread may also be cre- 
ated within the virtual machine itself, eg a garbage col- 
lection thread. 

[0062] As mentioned above, the present embodiment 
relies on a pre-emptive thread handling virtual machine 

20 such as that found in Java based systems. In such a 
machine, a plurality of threads are generated and stored 
in a thread queue. The scheduler inspects the thread 
queue and selects the thread with the highest priority to 
be executed. Normally, the thread that is being executed 

25 has the highest priority, but such a thread may be inter- 
rupted by a thread of yet a higher priority, as is conven- 
tional in pre-emptive threaded systems. In such a case, 
the state of the interrupted thread is stored and the 
thread re-activated once it reselected to be executed. 

30 [0063] In certain cases, a thread may itself include a 
so-called "yield" instruction which causes the scheduler 
to suspend the execution of the thread and to inspect 
the thread queue for any other threads to execute. The 
yield instruction may be present in low priority internally 

35 generated tasks, such as a garbage collection function 
carried out by the system in order to remove unused 
objects from the memory of the system. 
[0064] These aspects of the system are shown in Fig- 
ure 6. The creation of a thread at 4550 gives rise to a 

40 thread stored in the thread queue 4551 . The newly cre- 
ated thread has the state "init" at 4552. If no other 
thread has higher priority, the thread is executed by the 
instruction startO and will have the state "executable" at 
4553. If the instruction stopO is executed in the thread, 

45 the thread becomes "dead" at 4554. The thread may 
equally achieve this state if completed as indicated by 
the run()fini instruction. If a yieldO instruction in the 
thread itself arises, or a suspendO instruction external 
of the thread is executed, the thread is suspended and 

so given the state "non-executable" at 4556. 

[0065] Referring now to Figure 7, the interaction 
between the lower level operating system 4100, the 
event manager 4273 and the scheduler 4270 will now 
be described. Raw events signalled by the run-time 

55 operating system 4100 are passed via the device man- 
ager 4313 to the event manager 4273. In a preferred 
realisation, some prioritisation of the received events 
may be carried out by the device manager 4313 and/or 
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the multitask system used in the operating system 
4100. However, as will become clear, one of the advan- 
tages of the present system lies in the fact that, unlike 
the system described in PCT/EP97/02116, the handling 
of events is managed within the virtual machine 4250, 
thus enabling creator of the middleware layer to achieve 
complete control over the event handling procedure. 
[0066] In the present embodiment, events sent via the 
device manager 4313 are classified by their code and 
their type. The code identifies the characteristics of the 
event, for example, in the case of an event generated 
through operation of a remote control associated with 
the decoder, the code can identify the button 
depressed. The type identifies the origin of the event, 
e.g. the remote control. 

[0067] Upon receipt of an event signal, the event man- 
ager 4273 uses a routing table 4560 to determine the 
event priority and thread destination and inserts a corre- 
sponding event object 4564 into one or more threads 
4561 located within the priority based thread queue 
4562. One or more event objects 4564 may be stored 
within a given thread as represented at 4563. The event 
objects 4564 are stocked within the thread according to 
their priority classification. Event objects within the 
thread of an equal priority are classified by their time of 
arrival (FIFO). 

[0068] Upon receipt of an event, the event manager 
4273 signals its arrival to the scheduler 4270, which 
then examines the thread queue to see if a thread has a 
higher priority than the thread currently being executed. 
If so, the current thread is then suspended as described 
above and the new thread executed. In this manner a 
pre-emptive thread handling system is implemented. 
[0069] In this way, the preferred embodiment allows 
efficient handling of threads in the decoder so as to per- 
mit the system to respond quickly to event calls, even in 
the case where the system is processing an existing 
prior event. The disadvantages of the known single 
processor queue system are thereby overcome. 
[0070] Whilst the preferred embodiment has been 
described in relation to a pre-emptive system in which 
the arrival of an event causes the event manager to sig- 
nal the scheduler to interrupt execution of a thread, 
other implementations are possible. For example, in a 
time-slice system, the scheduler can periodically inter- 
rupt execution of a thread to examine the state of the 
thread queue. Alternatively, the scheduler can be 
adapted to interrupt execution of a thread to examine 
the thread queue after each instruction in that the 
thread is treated. 

MEMORY MANAGER 

[0071] As will be appreciated, in the context of 
receiver/decoder, the management of the memory pool 
within the system is particularly important, since mem- 
ory space is relatively restricted as compared to for 
example, a PC or other hard disk based platform. In the 



following description, the memory pool corresponds to 
the memory space within the RAM of the 
receiver/decoder. However, as mentioned above, the 
correspondence between the physical and logical 

5 organisation of the memory is not exact and the mem- 
ory pool described below may be located in or shared 
between other physical memory devices, such as a 
FLASH memory, an EEPROM etc, within the 
receiver/decoder. 

10 [0072] Referring now to Figure 8, this shows the 
organisation of the available memory in the system. It 
will be seen that the memory space is shared between 
a pool of handles 4600, a pool of displaceable objects 
4610 and a pool of non-displaceable objects 4620. 

is [0073] Each object in the pool 4610 is identified by 
and corresponds to a handle stored in the pool 4600. 
The relation between a handle and its corresponding 
object is managed by the memory management pack- 
age 4274 (see Figure 4) which also controls the access 

20 to the pool. All calls to objects in the pool are made by 
its handle. The boundary between the pools 4600 and 
4610 is movable. When a new object is to be stored in 
memory a handle is created in the pool 4600 including a 
pointer to the address of the object within the pool 4610. 

25 In such a case, the list of handles will be increased by 
one. The handles are organised in a list formation in the 
pool to permit compactage by the memory manager. 
[0074] Objects will be allocated in the pool as needed 
and according to the space available. In the case that an 

30 object allocation is demanded which requires more 
space in one block than is available, it will be necessary 
to compact the objects already allocated in the memory. 
The compaction of the objects in the memory can be 
carried out according to any known compacting algo- 

35 rithm, for example, a copy-compact algorithm. In the 
present embodiment, the Mark Sweep compact algo- 
rithm is used. In order to compact space, the objects are 
moved around in the zone 4610, so as to group objects 
more closely together, avoiding any spaces between 

40 adjacent objects. In this way, all free memory space is 
clustered together in a block so as to allocate for a new 
object in the pool 4610. 

[0075] As mentioned above, the memory manage- 
ment package maintains the correspondence between 

45 handles in the pool 4600 and objects in the pool 4610 
and the new addresses of the objects in the pool will be 
updated into the equivalent handles for future access. 
[0076] Whilst the use of a handles to access certain 
objects enables the system to optimise memory location 

so in the pool, the process increases the time needed to 
access such objects, since it is always necessary to first 
retrieve the handle in order to look up the address of the 
object. In certain situations and for objects correspond- 
ing to certain designated events a more rapid access 

55 time may be required. 

[0077] In such a case, the objects can be allocated in 
a pool of non-displaceable objects 4620. The address of 
such objects is fixed within the pool. There is thus no 
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need for the creation of a handle and the objects are 
used directly by the system, thereby simplifying the 
access procedure for these special objects. Again, as 
with the boundary between the pools 4600 and 4610, 
the boundary between the pools 4620 and 4610 will be 
shifted depending on the information stocked in the pool 
4620. 

[0078] In the event, for example, that a non-displace- 
able object is be allocated to the pool 4620 and there is 
insufficient space due to the arrangement of displacea- 
ble objects in the pool 4610, a compaction of the dis- 
placeable objects may be carried out, as described 
above. Once the objects in the pool are reorganised so 
as to liberate the maximum amount of space it may then 
be possible to allocate a non-displaceable block in the 
pool 4620. 

[0079] The choice of which objects are displaceable 
and which objects are non-displaceable is at the discre- 
tion of the designer. For example, objects correspond- 
ing to the system may be chosen as nondisplaceable in 
view of the importance of these objects, whilst high level 
application objects may be displaceable. In certain 
instances, displaceable objects can be temporarily 
locked into place so as to be considered as non-mova- 
ble objects. 

[0080] In order to eliminate unwanted objects from the 
memory pool the system may also include a so-called 
garbage collection. This involves the creation of a spe- 
cial garbage collector thread of the lowest priority which 
will be addressed by the scheduler in the event that no 
other threads are currently stored in the queue. Upon 
execution, all displaceable objects currently allocated in 
the pool that are not being referenced at that time will be 
freed. The garbage collector thread may also carry out 
compaction of all other displaceable objects along the 
lines described above. 

[0081] The creation of a garbage collector thread is 
known in the context of other multithread systems used 
in other applications outside of a digital television sys- 
tem and will not be discussed in any further detail here. 
However, it will be appreciated that use of a garbage 
collection procedure in combination with the other mem- 
ory management techniques described above provides 
particular advantages in the present context. 

Claims 

1. An apparatus for processing digital audio-visual 
data comprising one or more hardware devices for 
transmission and reception of data external of the 
apparatus, the apparatus further comprising a data 
processing system including a first virtual machine 
adapted to, inter alia, receive code written in an 
interpretative language downloaded via one or 
more of the hardware devices, said virtual machine 
being adapted to distinguish between code written 
in at least two interpretative languages in depend- 
ence on the structure of the received code and to 



pass such code to a corresponding interpreter 
means for interpretation and execution. 

2. An apparatus as claimed in claim 1 in which the vir- 
5 tual machine distinguishes between interpretative 
code in at least two interpretative languages based 
on the characteristics of a header message associ- 
ated with a module of code in one of the languages. 

w 3. An apparatus as claimed in claim 1 or 2 in which the 
virtual machine distinguishes between interpreta- 
tive code based on the presence or absence of a 
header message associated with a module of code 
in one of the languages. 

15 

4. An apparatus as claimed in any of claims 1 to 3 in 
which at least one of the languages is an object ori- 
ented language. 

20 5. An apparatus as claimed in any preceding claim in 
which the virtual machine identifies code written in 
an object oriented language by the presence of a 
header message associated with a class file in that 
language. 

25 

6. An apparatus as claimed in any preceding claim in 
which each interpreter means executes code with 
reference to one or more function libraries. 

30 7. An apparatus as claimed in claim 6 in which a com- 
mon function library is shared by a plurality of the 
interpreter means. 

8. An apparatus as claimed in claim 6 or 7 in which 
35 one or more of the interpreter means executes 

code with reference to a function library exclusive to 
that interpreter means. 

9. An apparatus as claimed in any preceding claim in 
40 which the apparatus is a decoder for a digital televi- 
sion system 

10. An apparatus as claimed in any preceding claim in 
which one of the devices comprises an MPEG 

45 demultiplexer. 

11. An apparatus as claimed in any preceding claim in 
which the hardware devices may comprise at least 
one of the following: a tuner, a serial interface, a 

so parallel interface, a modem and one or more smart 
card readers. 
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